FIG. 1 shows a network architecture of E-UMTS as a mobile communication system to which the related art and the present invention are applied. The E-UMTS system has evolved from the existent UMTS system and a basic standardization therefor is undergoing in 3GPP. Such E-UMTS system may also be referred to as a Long Term Evolution (LTE) system.
E-UMTS network may be divided into E-UTRAN and Core Network (CN). The E-UTRAN includes a terminal (User Equipment, referred to as ‘UE’ hereinafter), a base station (referred to as ‘eNode B’ hereinafter), a Serving Gateway (S-GW) located at the end of the network to be connected to an external network, and a Mobility Management Entity (MME) for managing the mobility of the UE. One or more cells may exist in one eNode B.
FIG. 2 shows a radio interface protocol architecture between UE and base station based on the 3GPP radio access network standard. The radio interface protocol in FIGS. 2 and 3 has horizontal layers comprising a physical layer, a data link layer and a network layer, and has vertical planes comprising a user plane for transmitting data information and a control plane for transmitting a control signaling. The protocol layers in FIGS. 2 and 3 can be divided into a first layer (L1), a second layer (L2) and a third layer (L3) based on three lower layers of an Open System Interconnection (OSI) standard model widely known in communications systems.
Hereinafter, each layer in the radio protocol control plane in FIG. 2 and a radio protocol user plane in FIG. 3 will be described.
A first layer, as a physical layer, provides an information transfer service to an upper layer using a physical channel. The physical layer is connected to its upper layer, called a Medium Access Control (MAC) layer, via a transport channel. The MAC layer and the physical layer exchange data via the transport channel. Data is transferred via a physical channel between different physical layers, namely, between the physical layer of a transmitting side and the physical layer of a receiving side.
The MAC layer located at the second layer provides a service to an upper layer, called a Radio Link Control (RLC) layer, via a logical channel. The RLC layer of the second layer supports reliable data transmissions. The function of the RLC layer may be implemented as a functional block in the MAC layer. In this case, the RLC layer may not exist. A Packet Data Convergence Protocol (PDCP) layer of the second layer, in the radio protocol user plane, is used to efficiently transmit IP packets, such as IPv4 or IPv6, on a radio interface with a relatively small bandwidth. For this purpose, the PDCP layer reduces the size of an IP packet header which is relatively great in size and includes unnecessary control information, namely, a function called header compression is performed.
A Radio Resource Control (RRC) layer located at the uppermost portion of the third layer is only defined in the control plane. The RRC layer controls logical channels, transport channels and physical channels in relation to configuration, re-configuration and release of Radio Bearers (RBs). Here, the RB signifies a service provided by the second layer for data transmissions between the terminal and the UTRAN.
In general, a dynamic radio resource scheduling is a method for informing radio resources to be used every time of a transmission or reception of UE. FIG. 4 is an exemplary view showing the operations of the dynamic radio resource allocation. Typically, an uplink radio resource allocation (e.g., UL GRANT) message or downlink radio resource allocation (e.g., DL ASSIGNMENT) message is transmitted via a Physical Downlink Control Channel (PDCCH). Accordingly, a UE receives or monitors the PDCCH at every designated time. Upon receiving a UE identifier (e.g., C-RNTI) allocated, then the UE receives or transmits radio resources indicated in the UL GRAT or DL ASSIGNMENT transmitted via the PDCCH, and then uses the radio resources to enable data transmission/reception between the UE and eNode B.
FIG. 5 is an exemplary view showing a detailed embodiment of HARQ applied to a downlink physical layer of a radio packet communication system. As shown in FIG. 5, eNode B decides a UE to receive a packet and a format of packet (coding rate, modulation method, data amount, and the like) to be transmitted to the UE. The eNode B then informs the UE of such information via the PDCCH, and thereafter transmits the corresponding data packet through a Physical Downlink Shared Channel (PDSCH) at an associated time. Thus, the UE can receive the information transmitted via the PDCCH so as to be known of the format of the packet to be transmitted to it and the packet transmission time, and also receive the corresponding packet via the PDSCH. After receiving the packet, the UE decodes the packet data. In case of a successful decoding, the UE transmits an ACK signal to the eNode B. The eNode B receiving the ACK signal may sense that the packet has successfully been received, thus to perform the next packet transmission. In case of an unsuccessful decoding, the UE transmits a NACK signal to the eNode B. The eNode B receiving the NACK signal may sense that the packet has unsuccessfully been received by the UE and accordingly retransmits the same data packet in the same format or a new format at an appropriate time. Here, the UE may combine the retransmitted packet with a packet which was received but failed to be decoded in various ways so as to attempt the decoding again.
As mentioned above, between the UE and the eNode B, a transmitting side performs the retransmission until it receives a HARQ ACK from a receiving side. However, in case where the transmitting side continuously receives a HARQ NACK from the receiving side, if the transmitting side keeps performing the retransmission, a delay of data transmission may occur. For example, referring to FIG. 5, if the transmitting side continuously receives NACK for Data 1 from the receiving side and thereby keeps performing the retransmission, the next Data 2 may not start to be transmitted. That is, the transmission of Data 2 is delayed. Accordingly, in general, when the HARQ operation is performed, the transmitting side should perform the transmission by setting how many times the retransmission should be performed for which data, namely, the maximum number of retransmissions. That is, the transmitting side would not perform the retransmission more than the maximum number of retransmissions.
However, a value such as transmission delay requirement depends on services. For example, a delay should be minimized for a voice call. Also, a delay may not be a problem for an Internet service. Therefore, the maximum number of retransmissions should differently be designated for each service.